beyondbinaryfandomcom-20200215-history
Encryption
Encryption is the information-theory equivalent of Occlumency in Harry Potter. When there is potential for 'bad-actors' in a communication network to intercept your private communications, it is wise to encrypt them (that is: 'scramble the frequencies' of the waves that generate your data in a way that an attacker won't be able to reverse-engineer). The 'reverse-engineering' of private data (Decryption), when applied to the mind of another person is Legilimency: mind-reading. Encryption as Occlumency The trick to Legilimency is knowing a wixard or wxtch's weaknesses. You don't read their mind because you are able to magically access their memories and internal voice, but rather you read it because you are able to provoke a state of vulnerability in the target, as happened when Harry accidentally penetrated Snape's childhood trauma during his extra-curricular training in HP6 (Half-Blood Prince). Snape was a more talented Occlumen than any other wxtch or wxzard of his time: able to shut his mind so completely that even He Who Must Not Be Named was unable to detect his lies. Yet, a teenage boy just learning legilimency for the first time was able to penetrate where Voldemort had never been able to go. The same is true of any encryption system, no matter how sophisticated they have become - the weakest link is always the humans who control and access this system. Decryption as Legilimency (coming soon) Penetrating someone's hidden secrets via solving their methods of concealing them (their encryption). Fully-Encrypted Networking Fully-encrypted networking Asymmetric privacy - invisible to some and visible to others (programmable) Frequency hopping (thanks to Hedy Lamarr) Temporal Validation Asymmetrically encoded periodic data. Individually meaningless messages, with entangled entropy If you store either half of the data then you can produce the other, since the timestamps will correlate Two pieces of reciprocal data will have the same timestamp, yet neither individually has any meaningful information Store hashes of the total data for each moment to validate the local hashes of each piece of cryptographic data published at that time Make the puzzle complex enough so that falsifying data with the same hash becomes intractable, especially since the extra layer of encryption requires that not only it share a compatible hash-value but also forms a pair with another member of the hash tree of that moment - a pair that together can be used to produce the decrypted message Almost like the two helixes of DNA... separate periodic waves of data that are co-dependent for carrying the total information of the chain Three-way Encryption Separate storage, decryption and processing. Find mutually-unbiased bases of data that can randomise eachother in ways that do not affect the decryption steps of one another. Meaning that the order of decryption is irrelevant. Separation of Payment and Verification Verification of financial history that is backed by "proof-of-stake" are most vulnerable to bloating of capital in the hands of those privileged few who hold significant stake in the economic tokens of said economy. A decentralised nanoeconomy functions so as to remove this constraint, with verification and payment being performed as independent modular elements of a three-way transfer of trust using primarily local resources. The only data that is ever transmitted across the full distance of a payment, is the hash-level data, reduced to a 'check sum' that verifies that there is a public record of the transaction in the public chain, such that anyone can verify when they see the transaction and its timestamp, that the transaction occurred at that time and had its contents encrypted into an X-bit hash that proves the transaction hasn't been altered later in time. Of course, it is possible to search through all the possible permutatiions of transaction data with the same timestamp until you find another that gives the same 'check sum' - but by choosing a check sum that is sufficiently strong, the odds of successfully falsifying such a transaction are minimal. Allowing both the receiver and sender of the transaction perform their own private encryptions on the data, and produce their own public 'check sums' they can reduce the potential of such attacks drastically. In this sense, there are now 'three' major steps of encryption protecting the data from ever being miscommunicated - a near-perfect ledger formed with near-zero trust between transactants. Transactors, Transfer & Timestamps # Send hashes of transactions (L1) # Mine hash combinations until someone creates a block of N transaction hashes whose combined hash solves some difficult puzzle (L2) # Allow separate encryption on transactor identities and transaction amount to be stored in side-chains time-synchronised to the hash of the latest block including its timestamp (L3) The first layer (L1) guarantees that the public chain does not carry the private information of the transaction - establishing one layer of privacy-encryption. The second layer (L2) is the block-mining challenge, creating a super-problem that minimizes the risk that any single computer could forge a transaction faster than the collective computing "swarm" of miners trying to solve the same puzzle with legitimate (un-forged transactions). This forms the primary layer of security-encryption. The third layer (L3) is necessary to prove that the encrypted transaction can not be forged AFTER the hash is recorded into the solution of the puzzle, essentially brute-forcing for spoof transactions that give the same hash as that written to the chain. Layer 1 (L1) allows for audit because the hash values of each transaction, while less-unique in terms of information content than their fully-decrypted versions, are chosen to be unique enough that accidental overlap is unlikely between similar messages, hence the chances of a forged transaction that solves the same hash problem existing that also has the correct method of syntax as other transactions, becomes negligibly small. An alternative layering, is to allow the hashed transactions to form the base of the mining problem in Layer 2 (L2), but to demand that the final hash value produced by L2's hashing problem and written to the blockchain/blockmesh is hashed from the concatenation of the full transaction set - unencrypted. However, this removes the privacy of L1 and is not considered an orthodox Three-Layer Encryption on this wiki). Once L2 has produced an computationally unpredictable set of transaction hashes that solve the chain's puzzle, the chain now permanently records the hash that solved the puzzle and the timestamp. Layer 3 (L3) now correlates this chain of hashes (which are too compressed to contain all the transaction information needed to produce a full ledger) into a partial-ledger for anyone who can solve the encryption methods used on side-chains to cross-validate the transaction hashes with a transaction matrix for that block that fulfils all of the net transactants transaction flows. The transaction matrix contains no individual flows but can be correlated by relative sizes of transactions (i.e. if one wallet increases +0.434 and another decreases -0.434, then its a strong signal for a shared transaction. However, transaction identities can be encrypted in L3 in ways that allow a node to be tracked enough to guarantee no double-spending has occurred, while also preventing leak of who that node transacted with? Node, Data & Processing Separation of identity of transactants from the transaction. Node identity is disconnected from the transactants, simply providing the source of data for the transaction to produce the necessary outcomes. Outflows of transactions occurring through multipartite reformations in which the ledger balance is known at any given time, but the specific transactions that cause the global ledger shift during each 'block' are not publically identified. A semi-private ledger. Nodes are used as points of transaction flow, while the transaction data can be stored off-chain through spactime entanglement between the hash and timestamp of the transaction block and the net change in the transactants ledger balance. Side-chains can be verified through the timestamps of their data-compilations. The compilation of on-chain data into verifiable side-chain data is through the hashing function, with the chain hash at any time formed as a verifiable function of the hashes themselves, such that every side-chain with a transaction compiled at the time of the block has a verifiable hash-history with that block (e.g. the block hash as a multiple of all side-chain hashes, or 'equal modulo the smaller hash'). On-chain data is kept very minimal, compilers use the hash and timestamp to build complexity off-chain into side-chain ledgers that track the true history privately, and are verifiable through cross-hashing of side-chain blocks with on-chain block timestamps and hashes. A block is formed on the main chain only when a necessarily large number of side-chains have prepared for the hashing routine which binds all side-chains to the 'clock' of the main chain. A further criterion of requiring the hash to take a certain adjustable form e.g. '################ < 0000009999999999' for a 16-digit hash), to control the speed at which side-chains can produce a hash value on average (e.g. 10 minutes for bitcoin's single-chain). In this way, the processing of the minimal on-chain data is verifiably secure due to being deterministically linked to the state of the hash of that on-chain block. Changing side-chain data post-hoc is then provably as difficult as finding two input data sets of similar ledger format that both give the same hash value to the main chain when hashed. As long as each side-chain employs a reliable hash routine, then the side-chains and the main-chain are considered secure. ---- np = 2113 [[Life Path 7|7] (last 6 was 栗島すみ子 (Kurishima Sumiko)), also prime (last was 2111 - Genghis Khan) Category:Cryptography Category:Information Theory Category:Quantum Information Theory Category:Communication Category:Quantum Cryptography